This invention concerns electronic mail, and in particular a correspondent-centric way of organizing and processing e-mail to enhance setup, ease of use, convenience, storage, and functionality of e-mail. For end-users the invention simplifies and improves the management of messages and e-mail addresses, helps manage and reduce junk e-mail, and makes it easier to manage multiple mail-boxes. The invention also helps organizations set up and manage group e-mail systems with less effort and inconvenience, and at lower cost.
E-mail is widely used today and its rapid growth is expected to continue. Over 70 million people use e-mail, sending over 200 million messages daily. Usage is expected to grow by 50% this year, with rapid growth projected for the foreseeable future
However, despite e-mail""s growing popularity, current e-mail systems have various drawbacks. These include the fact that e-mail systems are hard to use (particularly for non-technical users), that users are often plagued with excessive junk e-mail, and others drawbacks which will be described below.
The interface problems exist in part because the prior art for storing and displaying messages has evolved in a way that prevents users from readily monitoring key correspondence relationships. This prior art is based on a xe2x80x9cmessage-centricxe2x80x9d e-mail paradigm for storing e-mail and communicating information about e-mail to users.
By way of background, E-mail systems are generally either xe2x80x9cclient-server-basedxe2x80x9d or xe2x80x9chost-based.xe2x80x9d In client-server systems messages are forwarded to the server, which stores them until the client logs in and downloads them for use and storage on the client (often the server continues to store messages after sending them to the client). In these systems most of the processing takes place on the client, with the server acting as a xe2x80x9cstore and forwardxe2x80x9d agent. Examples of client-server-based systems include typical Internet e-mail provided by Internet Service Providers (or xe2x80x9cISP""sxe2x80x9d), who use free server softwares such as Sendmail, or proprietary server softwares such as CC-Mail or Microsoft Exchange. Their customers handle their mail using client softwares such as Eudora, or the mail readers packaged with Web browsers such as Netscape Navigator or Microsoft Internet Explorer.
In host-based e-mail systems, on the other hand, messages are stored and processed on the server rather than the client. Examples of host-based systems include (1) main-frame e-mail systems (where users connect using xe2x80x9cdumb terminalsxe2x80x9d), (2) private dial-in networks such as America On-line or Compuserve, and (3) Web-browser-based e-mail systems such as HotMail and Yahoo Mail.
The most widely used e-mail protocols today are POP3 and SMTP. POP3 (xe2x80x9cPost Office Protocol 3xe2x80x9d, as specified in RFC 1725) is an interface standard designed to facilitate mail management locally on the user""s e-mail device. Any POP3-compliant client can receive e-mail through a POP3-compliant e-mail server. (Note: a recent interface protocol, IMAP4xe2x80x94RFC 1730, is similar to POP3 except that it gives the client the option of sharing additional functionality with the server.) Likewise, SMTP (Simple Mail Transfer Protocol, as specified in RFC 821) is an interface used by e-mail servers to exchange messages with other servers. In order to exchange mail over the Internet, servers in both client-server and host-based e-mail systems must be SMTP-compliant.
POP3 and SMTP-based e-mail softwares create, send, and store e-mail in a standard format that does not lend itself to certain functions (that format is specified in RFC 822). These standard e-mail messages are self-contained strings of text, delimited into several standardized fields. Key fields in the messages text string include xe2x80x9cheaderxe2x80x9d information (e.g. sender""s e-mail address, recipients"" e-mail addresses, date/time sent, topic, etc.), and message xe2x80x9cbodyxe2x80x9d. Other fields can be appended, but are principally useful only if sender""s or receiver""s e-mail system can recognize and use them.
These e-mail softwares store and let the user view these messages in a standard way, using designated files (also called xe2x80x9cmailboxesxe2x80x9d or xe2x80x9cfoldersxe2x80x9d). The default files are typically an xe2x80x9cInboxxe2x80x9d and an xe2x80x9cOutbox.xe2x80x9d When a user sends a message the software typically creates a message text string which it appends to the sender""s xe2x80x9cOutxe2x80x9d file, then transmits the string over the network to the receiver""s e-mail system, where the text string is appended to sender""s xe2x80x9cInxe2x80x9d file. Users can create additional files (or xe2x80x9cfoldersxe2x80x9d), and can then move messages from the xe2x80x9cInxe2x80x9d or xe2x80x9cOutxe2x80x9d files to a new file, but this process typically requires manual effort or programming on the user""s part.
In prior art systems it is hard to organize, find, and view useful information about one""s correspondences. For example, end users can sort or view messages in only one file at a time (e.g. either the xe2x80x9cInxe2x80x9d-file or xe2x80x9cOutxe2x80x9d-file, but not both). Further, within a single file users can sort messages only by using a message field contained in the message itself (e.g. by date, topic, or sender""s e-mail address). Users cannot reliably or readily view information pertaining to correspondence with a single correspondent, which information is usually contained in two or more files. For example, users cannot see summarized, compiled information about their correspondence history with any one correspondent, nor can they readily view a chronological correspondence sequence of incoming and outgoing mail between themselves and a specific correspondent. Further, sorting mail by sender e-mail address does not consistently link messages to correspondents, because the sender and receiver address fields allow many different text formats for messages sent to the same e-mail address.
Another problem with prior art systems is that they don""t manage e-mail address lists well. Just as with handling of e-mail messages, the prior art handles e-mail address lists as flat files with no intelligent linking either to other e-mail address lists or to messages. Also, prior art e-mail address lists must be painstakingly created and managed by the user, rather than being automatically created based on correspondence.
The proliferation of junk e-mail is another problem with the prior art. Junk e-mailxe2x80x94often called xe2x80x9cspamxe2x80x9dxe2x80x94has lately become so pervasive that a Wall Street Journal article recently opined that spamming xe2x80x9chas no foolproof solutions.xe2x80x9d Unfortunately, it is impossible to prevent spam by excluding messages from offending e-mailers, because spammers can easily fake their sender e-mail address. The prior art attempted to deal with spam by letting users create e-mail filters in their local e-mail system. Such a filter sorts incoming e-mail for the recipient into categories determined by the user. The filter simply scans each e-mail message as it reaches the recipient and determines what category it should be placed into. One category is, of course, xe2x80x9cdiscard.xe2x80x9d Messages which the filter places in that category are automatically discarded. However, these filters have two disadvantages. First, they are hard to create, and consequently most e-mail user""s don""t bother to use them. Second, filters often filter out the good mail with the bad.
For example, an employee survey sent by e-mail may request the user to indicate his or her sex.
The xe2x80x9cmessage filtering techniquexe2x80x9d in U.S. Pat. No. 5,619,648 to Canale et. al. Apr. 8, 1997, attempted to reduce junk e-mail. However, it offered an entirely different type of solution than the Invention. U.S. Pat. No. 5,619,648 relied on inserting additional information into the standard flat message file. It further required that all third-party users also use its invention, so that patent""s application would only apply within closed loops of users.
Another frustration with the prior art is that it doesn""t make it easy to own and use multiple e-mail addresses. Many current e-mail users have multiple e-mail addresses, but find it difficult to access them at the same time from a single access device.
Various problems plague organizational users of prior art e-mail systems. One problem is that these systems are hard to set up, and it is hard for users to easily link to other users within the organization.
Another problem with the prior art that plagues organizations is that the prior art consumes excessive computer storage space. This happens in two ways. First, prior art systems store each message on multiple computers. For example, if a user sends a message to one recipient, that message is stored in two to four places (e.g., in client-server systems, the message is stored on sender""s client computer, recipient""s client computer, and often on both sender""s and receiver""s server; in host-based systems, the server stores the message in a file for the sender and again in a file for the receiver). Further if a user addresses a message to ten people, then as many as 22 identical copies of that message may reside on the clients and servers of the sender and his addressees!
The second storage problem with the prior art happens when a user wants to file a message under more than one topic. The prior art does this by filing a copy of the message in each file (or folder) selected by the user. If a prior art user wants to store a message under ten topics, then ten copies of the message will be stored (and in the more recent IMAP4 systems as many as 20 copies of the message will be storedxe2x80x9410 on the client and 10 on the server!).
The problems with the prior art exist because since the time of e-mail""s development in the 1960""s and early 1970""s, e-mail has been based on the currently outdated xe2x80x9cflat-filexe2x80x9d database technology. Flat-file databases, also called also xe2x80x9cnon-relationalxe2x80x9d databases, store information as a simple series of xe2x80x9crecordsxe2x80x9d, each containing identical xe2x80x9cfieldsxe2x80x9d of information (like subsequent rows a spreadsheet, each containing one field of information for each column of the spreadsheet). E-mail messages were structured as flat-file recordsxe2x80x94self-contained strings of text, delimited into various standardized fields. Key fields in each message""s text string included xe2x80x9cheaderxe2x80x9d information (e.g. sender""s e-mail address, recipient""s e-mail address, date/time sent, topic, etc.), and message. Other fields could be appended, but were principally useful only if both the sender""s and receiver""s e-mail system could recognize and use them.
Prior art e-mail systems store, manage, and display e-mail messages in limited ways dictated by flat-file database architecture. These systems typically file e-mail messages two or more designated flat files (also called xe2x80x9cmailboxesxe2x80x9d or xe2x80x9cfoldersxe2x80x9d). A file contains a series of messages, each of which is analogous to a record, analogous to a xe2x80x9crowxe2x80x9d in a table or spreadsheet (as described above). The default files are typically xe2x80x9cInbox,xe2x80x9d and xe2x80x9cOutbox,xe2x80x9d files. For example, when a user sends a message, his system typically creates a single string of text containing all the fields in the message, and appends this string to the the user""s xe2x80x9cOutxe2x80x9d file. The system then transmits the string over the network to the recipient""s e-mail system, where the text string is appended to the recipient""s xe2x80x9cInxe2x80x9d file. Consequently, each user""s In-box and Outbox grows longer and longer until the user does something with a message. Users can solve this problem by creating additional files (or xe2x80x9cfoldersxe2x80x9d), and can move messages from one folder to another. However, this approach takes thought and effort from the user.
In summary, some of the disadvantages of the prior art are:
1. It does not organize e-mail automaticallyxe2x80x94instead requires users to organize their e-mail manually; Inboxes and Outboxes grow large and unwieldy because messages are not automatically filed;
2. Hard to see on a single screen the chronological correspondence to and from a given correspondent;
3. Users cannot view on a single screen consolidated information about their correspondence history with multiple correspondents;
4. Hard to remember or find correspondents"" e-mail addresses;
5. Doesn""t remind users about key information triggers, such as whether the last correspondence with a party was incoming or outgoing, and which correspondences have lapsed.
6. Hard to find past messages;
7. Hard to view groups of past messages in meaningful ways;
8. Users can view messages from only one folder at a time;
9. Time consuming to set up, maintain, and use multiple e-mail address lists;
10. Hard to identify or screen junk e-mail;
11. Impractical to change one""s e-mail address;
12. Problematic for an e-mail user to own and manage more than one e-mail address;
13. Users who own multiple e-mail addresses find it hard to move selected contacts and their related correspondence history from one e-mail address to another;
14. Hard to share access to a single e-mail address with others;
15. Hard for organizations to instantly set up an e-mail network for their constituents;
16. Hard for organizations to set up and maintain a single or multiple e-mail address lists for their constituents;
17. Hard for organizations to regulate access to organizational e-mail address lists.
18. Uses excess network storage space because duplicate copies of each message must be stored in multiple network locations;
19. Uses excess storage space on user""s own computer, because duplicate copies of messages must be stored for each folder in which a message is filed;
In summary, the prior art provided a standard flat-file interface which has made it easier to write e-mail programs, but not easier to use them. Problems with prior art e-mail systems include the following: they are hard to use, don""t manage messages in optimal ways, fail to manage e-mail addresses well, suffer from excess junk e-mail, make it difficult to manage multiple mailboxes, and are inconvenient for organizations to set up and maintain.
The object of the invention is to provide a simple, easy-to-use, intuitive e-mail system with enhanced protections from junk e-mail, and which overcomes various drawbacks of prior art e-mail systems.
Accordingly, several objects of the invention are as follows:
1. View consolidated information about their correspondence history with all correspondents.
2. Easily view a chronological correspondence to and from a given correspondent.
3. Avoid the inconvenience of remembering or looking up e-mail addresses.
4. Eliminate or reduce junk e-mail by either screening incoming mail by correspondent, or conveniently changing one""s e-mail address while simultaneously effecting the change in the systems of desired correspondents.
5. Have their e-mail organized automatically by the system, rather than having to organize it manually.
6. More easily be reminded about certain key information triggers, such as whether the last correspondence with a party was incoming or outgoing, and which correspondences have lapsed.